About

  • Think minimum to solve the problem.

  • Think outside of OOP.

  • Reduce the number of abstractions.

  • What is the minimum to do this? Ignore any notion of OOP.

    • Ignore Godot Nodes notions, just consider the minimum.

  • Don't make a generic engine or a generic game, make YOUR game.

    • Do not necessarily be flexible / generic. That causes problems. It slows production.

  • Philosophy :

    • "The only purpose of any code is to transform data".

    • "The programmer's job is not to write code, but to solve data transformation problems".

    • "Writing the code is the tool you use to do your job".

    • "Therefore, only write code that has direct, provable value, that transforms data in a meaningful way".

    • "To understand the data is to understand the problem".

  • Organize data for performance (minimizing cache misses).

  • ECS and DOD generally go together.

    • ECS organizes data into separate components.

    • DOD optimizes how that data is accessed for better performance.

  • Excellent explanation of DOD .

    • It explains:

      • CPU.

        • Registers.

        • L1.

        • L2.

        • L3.

        • Main Memory.

        • Disk

      • What a CPU cache miss is.

      • Cache Line.

  • DOD, by Mike Acton .

    • Mike Acton, Insomniac Games.

      • Principal engineer of Unity engine.

      • He is reaaaally "rigid" and reaaaally aggressive about what he doesn't like, sometimes without elaborating much, or not being able to see the value in other things and other strategies.

      • "Anyone who wants to say 'premature optimization' can leave the room. That's the most abused quote of all time.".

      • {01:22:20} As shown here, "if the algorithm changes, the data changes and the code has to change". This left the questioner very frustrated, showing how absurdly inflexible Mike's design is.

      • "Why use C++ and not C?" "It's just a cultural choice, but if I had to choose I would use C 99".

    • {00:00 -> 28:30}

      • Very strict definition of what DOD is.

        • "Nothing here is necessarily new, it's just a reminder of important things".

        • He hates OOP, because OOP has a mentality that distances the problem from the Hardware and real problems, while valuing a set of abstract ideas and "metaphors" that move away from the real problem.

    • {28:30 -> }

      • "Can the compiler do it?"

      • "The compiler is a tool, not a magic wand".

  • Advanced explanation of DOD, by Andrew Kelley .

    • Andrew Kelley, creator of Zig.

    • Ideally watch the video above to better understand this one.

    • .

    • .

    • It only talks about 'memory footprint' (alignment, size).

      • .

    • After that it talks about a case study with the Zig Compiler

  • DoD and SOA in JAI, by Jonathan Blow .

    • {00:00 -> 47:40}.

      • He uses data composition, instead of inheritance, via the use of using  in procedures and structs to bring the contents of an object into scope.

        • The object has another object inside it, instead of the second object inheriting the first object.

    • {47:40 -> end}.

      • Demonstration of SOAs in JAI, via the keyword SOA .

      • A vector can be SOA , a struct can be SOA  via :: struct SOA { //etc }

  • Advice for programmers, by Mike Action .

    • It's a good video, with several useful tips.

    • The video is in Iran.

    • Commenting on the 'bad advice' given by people on Quora when asking "What are the most important programming concepts?"

    • I found it quite interesting and valuable.

    • Problems programmers normally have.

    • Learn to practice.

    • Have problem solving defaults established.

    • Problem solving targeted at the problem you actually have.

    • {29:24} Don't do something so generic, thinking about being absolutely flexible or future proof.

  • Problems with OOP, with Tony Albrencht .

    • The subject is somewhat repeated with other videos, but the video is ok.

    • Sony, Riot Games.

      • The last question in the video talks about LoL, but superficially, the rest is just about DOD.

    • Memory access has grown very slowly and became the bottleneck, so the CPU L1, L2 cache are super valuable.

    • Profiling finds the slow cases and it is noticed that it was due to cache misses.

    • {44:00} "Is OO bad?"

      • Logic/Function vs Data.

      • Data is the most realistic.

      • "OO used without care can produce slow, complex, unmaintainable and unoptimizable code".

  • Interview with Mike Acton .

    • Overall, the video is not worth it, nothing very useful.

    • Topics:

      • Team.

      • "The best solution is the one that works for your problem, with the least amount of abstraction".

      • Kinematics.

      • File format documentation.

      • Practice, etc.

  • Assembly Language is simpler than React / The problem of 30 million lines of code .

    • Only from {38:20}.

    • It's a very good video, from what I watched.

    • The problem of 30 million lines is based on:

      • Huge security problems due to extreme complexity of OS, Hardware APIs, etc.

      • Innovation problems because "it is extremely unlikely that any new operating system will be released that is purely not a fork of Linux, or a Mac mod, or something obtained by leaks from Microsoft".

    • Very interesting.